@fjl, thanks for your PR! By analyzing the history of the files in this pull request, we identified @zelig, @karalabe and @bas-vk to be potential reviewers.

@fjl thanks!

@fjl Oh, shoot. Tried to test under jsonrpc, it didn't work, noticed the previous commit and then your note. That's a problem for me, as I've put some time into building a development tool that expects compilation as a JSON-RPC service. I'm unhappy, but I guess I'll have to deal. Thanks for your help.

Please read the reasoning in ethereum/EIPs#209. I can see both sides.
What language is your tool written in?

@fjl if you do bring JSON-RPC support back under a different name, please let me know (and take this as encouragement!)

I did read it, and can see both sides too. My tool is written in Scala, https://github.com/swaldman/sbt-ethereum It basically plugs solidity compilation into sbt, a widely used Scala built tool, and allows contract deployment, convenient command-line interaction with the ethereum blockchain (lots of prompting through tab completion), and a database to track deployment artifacts. It's not yet stable (I'm reorganizing the DB schema a bit right now) so I haven't much publicized it, but it works very well, it's what I use for development and interaction with the blockchain.

It's very nice, from my perspective, to have the environment's sole unmanaged dependency be the existence of a running geth node. It would allow me to publish builds that are reproducible with no external dependencies except a running node, which I can host, and an installed JVM (which Oracle makes easy even for nontechnical users). I mean to template apps this way, not gigantic dApps with pretty GUIs and token sales, but small smart contracts users can modify and deploy to enter into economic relationships with people that they know. Requiring people to download solc (which is not so convenient for nondevelopers) is a big problem for this use-case. (I'll go ahead and make my case in the EIP conversation, but it looks like I'll be in a distinct minority.)

Thanks again.

Maybe you can use the wrapper provided by EthereumJ (see https://github.com/ethereum/ethereumj/blob/develop/ethereumj-core/src/test/java/org/ethereum/solidity/CompilerTest.java)

Thanks for the suggestion. I do appreciate all your help.

Wrapping solc isn't a big deal. (I don't think I'd bring in ethereumj and its dependencies just to do that.) It's the dependency on solc deployed locally that creates a burden on users who are not typically developers, but who might deploy contracts already provided as source (with or without small modifications).

You can also run the JS version of solc with Rhino. But that would add a dependency too ;)
In the end, someone needs to install the compiler somehow. If geth runs solc, the compiler needs
to be within reach of geth. If your users run it, they need to have the compiler. It's not a massive difference.

Yup! I'm not sure that'd be easier for users.

I can write my own network service just to compile solidity, but it was sure nice when you guys did that for me!

Out of interest, how did you provide it so far? I mean, did you run geth on a public endpoint to provide the compileSolidity API?

Yeah, it's up and available at http://ethjsonrpc.mchange.com:8545/

A trivial wrapper one can use to just execute a shell script and then "conveniently" interact with the blockchain by command line is here. It'll download and install all JVM-based external dependencies upon first execution, and just work without further ceremony. (An installed JVM is the only dependency.)

"Conveniently" is in quotes because right now there are too many commands. A user types eth<tab> and gets a lot of possibilities, not all of which are relevant to end-users. I want to segregate out the small number of common-use commands, so that this becomes a much clearer menu. And I want to stabilize the database that tracks deployments and compilation artifacts (ABI, metdata now, etc) before encouraging people to use this. (That's tonight's work!)

So, I've added a long complaint to the EIP...